Chapter 12 | Software Development

12.1 Program Development Cycle

The Software Development Life Cycle →

The software development life cycle (SDLC) is a process of developing a program, set out in 5 defined stages:

Analysis

• The investigation, leading to a specification of what the program is required to do
• The problem is clearly defined. A feasibility study is carried out, followed by an investigation & fact-finding
• Program specification is a document that is created
• A solution is planned. There may be more than one - use the most appropriate one
• Decide how to solve the problem:
  • Top-down: stepwise refinement using pseudocode, flowcharts, and structure charts
  • Bottom-up: small sub-problem is built on

Design

• Program specification is used to show how the program should be developed
• Identifier table is created, showing variable names, data types & explanations/descriptions
• Data structures defined e.g. 1d arrays, 2d arrays, ADTs
• A decision on the use of text files is made
• The algorithm is planned using pseudocode, flowcharts and structure charts
• The program is split into its modules

Coding

• Choose a suitable high-level language.
• Create code and programs for each module.

Testing

>

• Uses a variety of testing strategies (see later in the chapter) to ensure the program works as stated in the specification.
• Eliminates syntax, logic, and run-time errors.
• This includes:
• Dry runs
• Test plans
• Trace tables being created
• Some syntax errors only appear once translating using an interpreter/compiler.

Maintenance

>

• Occurs once the program is in full operation i.e. during use.
• Ensures it continues to work correctly.
• Deals with:
• Software upgrades
• Bug fixes
• Repairs
• Three types of maintenance:
• Adaptive
• Corrective
• Perfective (see later in the chapter)

Software Development →

>

Waterfall Model →

Linear, sequential model of development. Each stage is completed and signed off before the next stage begins. fully documented at each stage. Downward arrows indicate that the current stage has been completed and data will be passed to the next stage. Upwards arrows indicate that more work is needed on a different stage before this stage can be completed.

Benefits:

• Stages are clearly defined and don't overlap, making the model easier to understand.
• Documentation makes it easier to understand.
• Each stage has specific deliverables.
• Good for small programs.

Drawbacks:

• Hard to change requirements and measure progress.
• A working program is produced late in the life cycle.
• Not suitable for complex or object-oriented programming.

Iterative model →

Development starts with a small subset of program requirements, and repeated reviews are used to identify further requirements until a complete program is eventually made.

Benefits:

• Progress can be measured
• Working model is developed early, so it is possible to find issues & correct them quickly
• Customer evaluation and feedback early in the cycle
• Less costly to change requirements
• Suited for large projects

Drawbacks:

• Needs more resources
• Only good for large projects
• Design issues may arise, as not all requirments gathered at the start.

Rapid application development (RAD) model →

Developing different parts of the program in parallel by teams of programmers. Uses prototyping and high customer involvement

Benefits:

• Reduced overall development time.
• More productive, as it requires fewer people & shorter time.
• Frequent customer feedback & quick initial reviews.
• Easy to change requirements & measure progress.
• Components can be reused.

Drawbacks:

• The system must be modular, component-based, and scalable.
• Needs a strong team of skilled designers and developers.
• Not suitable for short and simple projects.
• Needs user involvement for the entirety of development.
• Can't estimate time/cost.
• Little to no documentation.

12.2 Program Design

Finite State Machines

A finite state machine (FSM) is a machine that consists of a fixed set of possible states, inputs to change the states, and a set of outputs.
State-transition table gives information about inputs and events.
States are represented as circles.
Transitions are represented as arrows.
Events are represented as arrow labels.
Stopped state is indicated by a double circle.

Important Definitions

• Accepting state: state a system reaches when input is valid
• Event: something that can happen in a system that may trigger the transition to another state
• Guard condition: a condition that must be met for a transition to occur
• State: value/position of a system at a given point
• Transition: change from one state to another

Structure Charts

A structure chart is a graphical representation and modeling tool used to decompose a problem into smaller sub-tasks. It shows module relationships.

12.3 Program Testing and Maintenance

Errors & Testing →

Errors →

Syntax error -an error in which a program statement does not follow the rules or grammar of a programming language

Logic error - error in the logic of a solution that causes it not to behave as intended

Run-time error - an error that causes program execution to freeze or crash due to invalid operations and extreme conditions

• Arithmetic: negative roots, division by 0
• Overflow: variable holds a value too large
• Stack overflow: no more space on a stack
• Library: program calls a function without importing the correct library

Ways to minimise errors:

• Use extensively tried & tested library routines
• Use modular programming, as it breaks down a problem into sub-tasks
• Use good programming practice:
• Sensible variable names
• White space
• Indentations
• Comments
• IDE features such as type-checking, auto-complete, debugging(variables, expressions and report window, single stepping, breakpoints), dynamic syntax checks, context-sensitive prompts

Testing strategies →

• Dry run testing: Code is manually traced, value of variable is manually followed to check if its used and updated as expected, used to identify logic errors but not execution errors
• Walkthrough testing: the program is checked by creating a trace table & going through the program line by line, to record any variables as they change. Errors are indicated when a variable gives an unexpected value, or by an unexpected path taken in the program. Faults in the logic of the program can be detected.
• Stub testing: A stub is a simple module, which is written to replace each sub-routine. This has a simple output to acknowledge that the call is made. Stub testing is used before the code is fully completed.
• Integration testing: Individually tested modules are joined to one program and tested to ensure modules interact correctly
• Black-box testing: Compares actual results when a program is run to the expected results, and tests if programs meet specific requirements. They check program specification and use it to devise test data and work out expected results. test data is devised - normal boundary and extreme. The code is unknown. Test plants are used (store inputs, outputs, expected outcomes, test data, reasons, results)
• White-box testing: Tests every path and every line of code using suitable test data. tester views the code
• Alpha testing: Software is tested in-house by dedicated testers. Programmers who pretend to be users, check requirements and deal with flaws
• Acceptance testing: Checks if the program performs as needed by customers before sign-off. Acceptance criteria is set and end-user feedback is used to ensure the criteria is met.
• Beta testing: Final stage of testing before release. Users test it under realistic conditions, and feedback is obtained. Checks if the program meets requirements and performs as it should. Problems are reported to the developer and are addressed/corrected.

Test Data →

• Normal: Typical data values; in range and should be accepted
• Abnormal/Erroneous: Data values that are out of range and should not be accepted
• Boundary/Extreme: Data values on the boundary or extreme end of a range of normal data, including values just within (normal) and just outside (abnormal) the boundary

Maintenance →

Corrective maintenance →

• Correcting identified errors, called bugs
• Work is required when program is not working correctly due to a logic or run-time error
• The program does not operate as expected
• Sometimes errors don't become apparent for a long time
• Earlier corrective maintenance may introduce errors

Adaptive maintenance →

• Amending a program to enhance functionality or in response to specification changes
• To accommodate a change in the requirement/technology/legislation
• Performs a function it was not originally designed to do

Perfective maintenance →

• Modifying a program to improve performance or maintainability
• The program runs satisfactorily, but there is still room for improvement